【保存版】東京リージョンの AWS 障害発生時にクラスメソッドのテクニカルサポートチームがやっていること

クラスメソッドのテクニカルサポートチームでは、お客様に最高のサービスを提供するべく、日々サポートの品質向上に取り組んでいます。こちらの記事では、テクニカルサポートチームで培ってきた、東京リージョンの AWS 障害対応手順を大公開します。

障害対応

#テクニカルサポート

#障害対応

Takaaki Kakei

2021.03.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、クラスメソッドの筧です。

2021年2月19日23時50分頃に東京リージョン（AP-NORTHEAST-1）で AWS 障害が発生しました。クラスメソッドのメンバーズサービスをご利用いただいているお客様の多くが東京リージョンを活用されている背景もあり、東京リージョンの AWS 障害が発生した際は、ベストエフォート型ではありますが、より迅速に行動できるよう日々チームとして心がけております。こちらの記事では、東京リージョンの AWS 障害について私達がどのような事前準備をしているか、どういう対応をしているかをご紹介します。

前提

はじめに、言葉の定義やチームの体制を共有します。以下の観点で、こちらの記事の前提をご紹介します。

AWS 障害
チームの勤務形態や制約
利用サービス

AWS 障害

こちらの記事での"AWS 障害"という言葉は、"東京リージョンの AWS 障害"という前提で書きます。一方で、他の障害対応にも通じる内容もあるかと思いますので、使えそうな内容があれば持ち帰っていただけると何よりです。

チームの勤務形態や制約

会社全体として98%の社員がテレワークで働いています。ちなみに、残り2%は郵便物の受け取りや工事立ち会い等、必要な場合のみ出社するケースです。またテクニカルサポートチームは、3ヵ国の拠点に分かれて24時間365日の対応を行っています。

上記の背景から、オフィスにいなくても円滑な対応ができるように意識して準備をしています。

利用サービス

テクニカルサポートチームが主に利用しているサービスを紹介します。以下のサービス以外にも、より良いものがあれば随時入れ替えたり、使い分けたりしています。

サービス	用途
Slack	社内チャットツール
Google Workspace	Google Meet や Google ドキュメントなどを含むグループウェアツール
Zendesk	問い合わせ管理ツール
Confluence	手順書などを整理している社内 Wiki

どのような事前準備をしているか

有事の際は想定外のことが発生しやすく、事前準備をしていないと冷静な対応が難しくなります。いきなりしっかりした事前準備をすることは難しいので、徐々に成熟度を上げていきます。本章では以下の観点で、事前準備についてご紹介します。

手順書
自動化
訓練

手順書

フローやチェックリストを含む手順書を準備しています。手順書の内容は後述します。分かりやすい手順書を準備することも重要ですが、その手順書への導線づくりも大切にしています。運用周りのドキュメントは数が多く、目的のドキュメントが埋もれてしまい他のメンバーが見つけられない場合があるからです。周知に加えて、ドキュメントの階層を見直したり、特定チャンネルに手順書の URL をピン留めしておくなど、手順書に辿り着きやすくする工夫をしています。

分かりやすい手順書の書き方については、以下のブログが参考になります。

手順書を書くときに気をつけていること | DevelopersIO

自動化

可能な限り自動化しています。最近では AWS 障害用の一次対応支援ツールを開発しました。機能の概要は以下の通りです。

障害専用の Slack チャンネルの作成
障害専用の Slack チャンネルで各対応を指示
他の Slack チャンネル（全社チャンネルなど）で社内メンバーへの情報共有
事前に用意している Google ドキュメントのテンプレートをコピーして、お客様向け通知内容の原稿用意

導入効果としては、自動化による対応速度向上と負荷軽減だけではなく、障害専用の Slack チャンネルに TODO 形式で次の対応が指示されることで手動対応のやりやすさも向上しました。 TODO ごとに個人のリアクションを押せば、誰が対応しているかを把握できますし、スレッドに対応進捗を書けば、タイムリーな対応状況を確認できるからです。

一次対応支援ツールは、Google Apps Script と Slack API で実現しています。 AWS 障害を想定しているので、AWS を使っていないのがポイントです。以下のブログに開発コードを載せているのでよかったらご覧ください。

Google Apps Script で緊急対応時の Slack 操作を自動化してみた | DevelopersIO

訓練

AWS 障害を想定した訓練を定期的に実施しています。直近では、当該障害発生の約2週間前（2021年2月2日）に訓練を実施していました。クラスメソッドのテクニカルサポートチームは、3ヵ国の拠点に分かれて24時間365日の対応を行っているので、全員で訓練することがなかなか難しいですが、今後は訓練を録画して共有することで参加できないメンバーへの共有もしていきたいです。

また訓練の振り返りを大切にしています。障害発生後だけではなく、訓練実施後もチームで振り返りを行い、費用対効果を考えて、やること・やらないことを明確化した上で対応しています。振り返りは主に KPT を採用しています。 KPT については以下のブログが参考になります。

ふりかえりの進め方を見直すため「ダメふりかえりを撲滅する3つのヒント」を読んだ #技術書典 | DevelopersIO

どのような対応をしているか

以下のフェーズに分けて、対応実施しています。

検知
事象確認
対応開始
一次対応
発生事象と他の項目を確認
収束

1. 検知

予兆を検知した場合、大小に関わらずオペレーション部の管理職、リーダーに Slack の 24時間365日ヘルプ部屋でメンション通知します。予兆は、お客様からのお問い合わせや Twitter など様々です。予兆段階では内容が曖昧な場合があるので、メンションする人は下記をなるべく正確に伝えることを心掛けます。

情報源（お客様からのお問い合わせ、Twitter など）
対象サービス（EC2、RDS、CloudFront など）
障害内容（リージョンはどこか？AZ 障害なのか？どのような影響が出ているのか、影響が出そうか？）

また、コミュニケーション円滑化のために、Google meet を作り関係者を集めます。 http://meet.new/で手軽に専用の meet を作れます。

2. 事象確認

AWS を利用しているサービスやツールの稼働状況を確認します。予め関係ツールの洗い出しを行い、誰にどこで何を確認するのか明確にしています。

また AWS Service Health Dashboard や AWS Personal Health Dashboard、お客様からの問い合わせなどを元に、AWS 障害か判断します。実際に事象が確認できたら対応に移ります。事象が確認できない場合は、そもそもなにを復旧すべきか分からない状況なので対応不要と判断します。観測範囲では発生しないがソーシャルネットワークサービス等での情報では継続している場合には、引き続き再現方法(発生条件)を確認します。もしくは割りきって一次対応(暫定対応)を実施します。再現方法を特定しても事象が解消するわけではないので、あまり再現方法の解析に時間を取られないようにしています。そして再現方法や原因を特定せずとも事象解消優先で一次対応を進めます。

3. 対応開始

司令塔を1人決めます。それ以外の役割は、その時に対応可能な人数にもよるのであえて決めていません。司令塔が決まったら、先述の一次対応支援ツールを実行します。

4. 一次対応

以下の流れで対応を行います。一次対応支援ツールによって、チャンネル作成や社内連絡は自動処理され、手動処理が必要な対応については専用チャンネルに TODO 形式で指示されるので逐次処理をします。

4.1 障害対応をハンドリングする為に、全社の情報共有場を作る（チャンネル・Meet準備）
4.2 社内の初動を早める為に、各部署に情報共有する
4.3 お客様への情報共有の為に、社外向け文面を作成してご連絡
4.4 お客様からのお問い合わせ対応の為に、Zendesk 側の整備（専用ビュー作成・一次回答案作成など）
4.5 状況確認の為に、TAM ¹ に連絡する
4.6 情報整理の為に、Confluence を整備する
4.7 対応漏れ防止の為に、専用チェックシートでダブルチェックする

5. 発生事象と他の項目を確認

一次対応が完了したら発報した事象が解消しているか継続して確認します。また、他の事象が発生していないか確認します。障害対応中は事象に集中するため視野が狭くなりがちなので、一息ついたところで全体を俯瞰し問題が発生していないか確認します。クラスメソッドでは進捗があり次第、専用ポータルで障害情報を更新しています。

前述の通り、クラスメソッドのテクニカルサポートチームは、3ヵ国の拠点に分かれて24時間365日の対応を行っているのでそのため別リージョンへの引継ぎも実施します。状況説明漏れを防ぐために、引継ぎは文章だけではなく、Google Meet を使い口頭でも実施しています。

6. 収束

復旧を確認したら、お客様に収束宣言します。前述した KPT などで対応の振り返りを行い、改善を行います。

まとめ

最後まで読んでいただきありがとうございます。

AWS 障害は頻繁には発生しませんが、いつ発生するかは分かりません。発生に備えて日頃準備しておくことが重要です。こちらの記事をキッカケに障害対応の準備について見直してみてはいかがでしょうか。

クラスメソッドのテクニカルサポートチームも、お客様により良いサポートを提供するべく、引き続き改善していきます！！この記事が多くの方の一助になれば幸いです。

更新内容

TAM の記述について訂正致しました(2021年4月28日)
アイキャッチ画像変更（2021年5月12日）
アイキャッチ画像変更（2021年5月12日）
「あわせて読みたい」のリンク更新

AWS エンタープライズサポートを契約することにより、担当の AWS テクニカルアカウントマネージャー (TAM) の協力が得られるため、弊社サポートチームは AWS と密に情報共有を行い障害に関する情報の収集を実施しています。 ↩
クラスメソッドのカルチャーを示した Classmethod Leadership Principle の略称です。詳しくはこちら。 Classmethod Leadership Principle | classmethod ↩